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TRANSMIT CHANNEL REQUEST MESSAGING FOR HALF -DUPLEX VOICE 

COMMUNICATIONS SYSTEMS 

FIELD OF THE INVENTION 

The invention relates to wireless communications 
5 systems and more particularly to messaging in wireless 
communications systems having half-duplex voice 
communications services . 

BACKGROUND OF THE INVENTION 

Communication systems are available which provide 

10 walkie-talkie-like functionality or similar half-duplex 

voice functionality which may take the form of PTT™ (push- 
to- talk™) over a dispatch service, ptt™ over cellular (PoC) 
services (part of the OMA standard), or otherwise. When 
referred to herein, walkie-talkie-like functionality and 

15 half-duplex voice functionality are to be taken generally to 
mean any network delivered voice communication functionality 
which at any one time is capable of transmitting voice 
communication from a talking or transmitting party's device 
to a listening or receiving party's device, but cannot 

2 0 simultaneously transmit voice communication from the 

receiving party's device to the talking party's device, 
while the talking party's device is transmitting voice to 
the receiving party's device. During an active ptt™ session 
or dispatch call session, only one user device (the 

25 "talker's" device) participating in the session may be 

designated as the transmitting or talking device at any one 
time. A user device gains the role of transmitting device 
by requesting the talk/ transmit channel from the network and 
by being granted the talk/ transmit channel by the network. 

30 While a talker's device is in possession of the transmit 
channel (during a talk period) , all of the other devices 
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(listeners' devices) in the active dispatch call session are 
in listener mode and cannot transmit voice until the 
transmitting device requests the network to terminate the 
talk period and release the talk/transmit channel . Times 
5 during which the talk/transmit channel is not occupied are 
idle periods. In standard implementations of ptt™, the user 
interface of, for example, a mobile device, includes a PTT™ 
button to allow the user to control the sending of requests 
to acquire and release the talk/transmit channel, these 
10 requests being sent over a logical control channel to the 
network. 

An example of a system providing PTT™ 
functionality as part of its dispatch services is the iDEN^" 
system of Motorola^". Other example systems which can 

15 provide such ptt"^^ services are IxRTT CDMA, UMTS, GSM/GPRS, 
and TDMA. Push- to- talk™ service may be provided as an 
optional half-duplex service over existing network systems 
which also provide for full -duplex communication, or may be 
provided as a service over network systems which provide 

20 only half -duplex communication. 

SUMMARY OF THE INVENTION 

The present invention provides for a method, 
system, and device for transmit channel request messaging in 
half -duplex voice communication systems. A new transmit 

2 5 channel request message (TCRM) is provided and sent over a 

logical control channel from a receiving device to a 
transmitting device while the transmitting device is in 
possession of a transmit channel in an active half -duplex 
dispatch call session, the TCRM indicating that the transmit 

3 0 channel is requested. In some embodiments, the invention 

provides for the conveying of information via the 
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transmitting device user interface (UI) indicating, that 
while the transmitting device is in possession of the 
transmit channel, another user wishes to talk. In some 
embodiments, the information includes an indication that 
5 another device has requested the transmit channel and 

preferably includes an identification of the device which 
sent the transmit channel request message . In some 
embodiments, a qualifier flag in the TCRM is used to specify 
what, if any, extended functionality in respect of the TCRM 
10 is to be performed. 

According to one broad aspect, the invention 
provides for a method of messaging during an active half- 
duplex session between a plurality of user devices capable 
of walkie-talkie-like functionality, the method comprising: 
15 a first user device of said plurality of wireless devices 

while in a receiving in half-duplex (RHD) mode for an active 
half -duplex session, transmitting a transmit channel request 
message (TCRM) to a network; the network forwarding the TCRM 
to a second user device of said plurality of user devices 
20 while the second user device is in a transmitting in half- 
duplex (THD) mode for the active half-duplex session; and 
the second user device receiving the TCRM. 

According to another broad aspect, the invention 
provides for a user device capable of walkie-talkie-like 
functionality adapted to participate in an active half- 
duplex session, the user device comprising: means for 
receiving an external input requesting the user device to 
transmit an outgoing TCRM message; means for transmitting 
the outgoing TCRM to a wireless network responsive to the 
request; means for receiving an incoming TCRM message from 
the wireless network while the user device is in transmit 
half -duplex mode; and means for generating a user-detectable 
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notification in response to receiving the incoming TCRM 
message . 

According to a further broad aspect, the invention 
provides for a network adapted to facilitate an active half- 
5 duplex session involving an RHD device capable of 

walkie-talkie-like functionality and a THD device capable of 
walkie-talkie-like functionality, the network comprising: a 
message processing element adapted to forward a TCRM from 
the RHD device to the THD device by: i) receiving the TCRM 
10 over an input channel from the RHD device; ii) processing 
the TCRM to identify from the TCRM the identity of the THD 
device; and iii) transmitting the TCRM over an output 
channel to the THD device . 

According to yet another broad aspect , the 
15 invention provides for a memory for storing data for access 
by a THD device of a network, comprising: a data structure 
stored in said memory, said data structure being a TCRM and 
comprising an identification of an RHD device. 

Other aspects and features of the present 
20 invention will become apparent to those of ordinary skill in 
the art upon review of the following description of specific 
embodiments of the invention in conjunction with the 
accompanying figures . 

BRIEF DESCRIPTION OF THE DRAWINGS 

25 Preferred embodiments of the invention will now be 

described with reference to the accompanying diagrams, in 
which: 



FIG. 1 is a block diagram illustrating example 
transmit channel request messaging in an active PTT"^*^ session 
3 0 of a group according to an embodiment of the invention; 
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FIG- 2 is a flow diagram depicting steps performed 
by a system to implement transmit channel request messaging 
according to another embodiment of the invention; 

FIG. 3 is a block diagram of a transmit channel 
5 request message data structure in accordance with a further 
embodiment of the invention; 

FIG. 4 is a conceptual block diagram of a network 
provided by an embodiment of the invention; and 

FIG. 5 is a block diagram of an example 
10 implementation of a PTT™ capable wireless device provided by 
an embodiment of the invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 

Users on the receiving end of a push- to-talk*'"'^ 
session held on known systems have no way of communicating 
15 to the user of the transmitting device, since the 

talk/transmit channel is occupied by the transmitting device 
until released. As such, prior to the present invention 
there was no mechanism to inform the user of the 
transmitting device that another user wishes to talk. 

Referring now to Figure 1, transmit channel 
request messaging according to the invention will now be 
described in the context of an active dispatch call session 
for a PTT*^" group of wireless mobile devices in a half-duplex 
dispatch system. More generally, embodiments of the 
invention are applicable in the context of wireless devices 
and networks which participate in network delivered walkie- 
talkie-like functionality, PTT"^" being but one example. A 
network capable of delivering this will be referred to as a 
''dispatch network" . 
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Shown is a ptt™ group (indicated generally by 
reference numeral 10) consisting of a group of mobile 
devices participating in an active PTT™ session while a 
transmit channel is possessed. The group contains a single 
5 mobile device 20 in THD (transmitting in half-duplex) mode 
which is in talk/transmit mode and in possession of the 
transmit channel, and a set (only four shown) of devices 
3 0,34 in RHD (receiving in half -duplex) mode which are in 
listening mode. It should be understood that transmit 

10 channel messaging is equally applicable to embodiments in 

which the dispatch call session only involves two devices (a 
1-to-l session) or which involves more than two devices (a 
1-to-many session) . To simplify this description, a device 
in THD mode or RHD mode will be referred to as a THD device 

15 or an RHD device respectively. However it is to be 
understood these are temporary designations for the 
particular mode of operation of the device at any particular 
time. During the active session, the users of the RHD 
devices (30, 34) are referred to as listeners, while the 

20 user of the THD device 20 is referred to as the talker- 
Each device of the specific embodiment shown in Figure 1 is 
capable of functioning either as a THD device or an RHD 
device, depending upon which device is in talk/transmit mode 
and which devices are in listening mode during any 

25 particular active session. 

The establishment of the physical links between 
devices of the users, the routing of voice data packets, and 
the duplication of voice data packets to each of the devices 
in listening mode are specific to each implementation of a 
30 PTT"^" or similar half-duplex voice communication system. 

These functions are represented abstractly by links 25 which 
represent all of the system components necessary to 
communicate the voice data sent by the THD device 2 0 to all 
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of the RHD devices 3 0 and in general support the functions 
of an active session. The details of these links are not 
relevant here. During the active session, the THD device 20 
possesses the talk/transmit channel until it requests 
5 release of the channel or terminates the call. 

According to a preferred embodiment, an example of 
which is depicted in Figure 1, during an active session a 
listener's device 34 in listening mode is adapted to send a 
transmit channel request message (TCRM) 3 6 over a logical 

10 control channel 3 8 in response to external input from the 
listener. In the illustrated example the external input 
occurs when button 3 5 is depressed. The logical control 
channel 38 may be a control channel, data channel, or 
dedicated messaging channel depending upon the system in 

15 which the messaging is implemented. More generally, any 
channel that allows the network to receive an indication 
that the user has requested the transmit channel may be 
employed. While referred to herein as a ''message", this 
encompasses any signal sent by the wireless device to 

20 achieve the desired effect. The TCRM 36 is received by the 
network 3 9 and forwarded to the THD device 20. The message 
is forwarded to the THD device on logical control channel 41 
which has the same options for implementation as the logical 
control channel 38. It is noted that the network 39 

25 represents all system components necessary to receive a TCRM 
message from an RHD device and forward this on to the THD 
device 20. This functionality may overlap partially, 
completely, or not at all with the functionality generally 
represented by 2 5 which provides normal PTT™ voice 

30 capabilities . 

In an embodiment implemented in the iDEN™ system 
of Motorola™, a preferred logical control channel is the 
data link layer sometimes referred to as layer 2 used to 
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send a TCRM 36 in the form of a layer 3 message. The TCRM 
could be sent over the L2 control channel, could be sent 
over a dedicated control channel (DCCH) , or an associated 
control channel (ACCH) . The TCRM 36 is forwarded by the 
5 network to the THD device 20. The dispatch call control 
functions of the iDEN™ system are controlled by the 
interaction of a DAP (Dispatch Application Processor) 
server, with the EBTSs (Enhanced Base Transceiver Stations) 
and the mobile devices. In an example implementation the 
10 combination of EBTSs and any intervening part of the network 
which forwards the TCRM 36 from the listener's RHD device 34 
to the THD device 20 fulfills the role of network 39. 

Once the THD device 2 0 receives the TCRM 3 6 from 
the network 39, an indication that another user has 

15 requested the transmit channel is generated on a user 

interface (UI) of the THD device 20. In the illustrated 
example, this is presented by shading an area 21 on the 
device 20 in THD mode. In some embodiments this takes the 
form of an alphanumeric indication on an LCD display, but 

20 other indications are also contemplated, including but not 
limited to vibrations originating in the device, audible 
alarms from a speaker, synthesized speech announcements, a 
UFMI (Urban Fleet Member Identifier) flashing on a visual 
display screen or appearing in a pop -up window on the 

25 screen. In some embodiments, information identifying the 
user making the request is included in the TCRM 36. This 
information could be, for example, a UFMI. This may be 
added to the TCRM message either by the RHD device itself or 
by the network. The THD device 20 may display the identity 

30 of the user's device which sent the request, which may take 
the form of the UFMI itself, or an alias stored in the THD 
device 20 for display in place of the UFMI. The display of 
this information provides to the talker an opportunity to 
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choose to release the talk/transmit channel or to continue 
to talk and keep ownership of the talk/transmit channel. 

Referring now to Figure 2, steps performed by a 
system to implement transmit channel request messaging 
5 according to another embodiment of the invention will now be 
discussed . 

At step 100, during an active session, an RHD 
device, for example RHD device 34 of Figure 1, of a listener 
locally receives a request to generate a TCRM. This could 

10 be an input initiated by the listener or initiated by an 
automated function local to the device. In response to 
this, at step 105, the RHD device generates a TCRM. In some 
preferred embodiments, the TCRM is generated if the listener 
presses, at a time during which the talker is speaking and 

15 the transmit channel is occupied, a PTT™ button or a button 
specifically designated for the TCRM. In a preferred 
embodiment, the TCRM is not generated at the RHD device 
unless the talk/transmit channel is occupied at that time, 
and moreover in another preferred embodiment, once the 

2 0 talk/transmit channel is released, any TCRMs in transit 

within the network will not be forwarded any farther towards 
the THD device. Other types of input mechanisms are also 
contemplated such as, but not limited to, selection from a 
menu of RHD device functions by keypad or input pen or by 

25 voice activation initiated by the listener. The RHD device 
then transmits the generated TCRM to the network at step 
110. At step 120, the network receives the TCRM and 
forwards it to the appropriate THD device in step 130. The 
THD device receives the TCRM at step 14 0. The THD device 

30 then executes functionality in response to the receipt of 
the TCRM at step 150 which in a preferred embodiment 
includes generating a notification in the THD device which 
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is user-detectable (i.e. by the talker) indicating that 
another user has requested the talk/transmit channel. 

Although the TCRM is typically implemented for the 
purpose of indicating that the listener wishes to talk, the 
5 TCRM may also be used by a listener to simply request that 
the THD device release the talk/transmit channel. The 
notification preferably is made on an LCD or other visual 
display user interface (UI) and preferably includes an 
identification of the user requesting release of the channel 

10 as discussed above. In another example, an audible 

notification may be generated, for example, synthesized 
speech announcing to the user that the TCRM has been 
received, and preferably announcing the identification of 
the listener making the request. After the indication has 

15 been made to the user of the THD device, the system 

functionality associated with subsequent actions of the 
talker to release or keep the channel, and of the listener 
to commence a new talk period after the talk/transmit 
channel is free, is the same as that which occurs when 

20 talk/transmit channels are released and talk periods are 
initiated when no TCRM is sent or received. 

In some embodiments, 'after the network receives 
the TCRM from the RHD device, the network (for example using 
a call processing server such as the DAP in the iDEN^" 

25 system) uses the device identifier in the TCRM to look up 
the current ptt™ group session in which the RHD device is 
participating. Alternatively, if the logical control 
channel used by the wireless device to transmit the TCRM is 
unique to that wireless device, the network can figure out 

3 0 which device sent the TCRM from the channel on which the 
TCRM was received. The call processing server then 
retrieves the group identification from the active group 
having the group session, and then armed with this 



51085-3 

11 

information retrieves the device identification of the THD 
device. The identification of the THD device is then 
inserted into the header of the TCRM as is normally 
performed when the DAP forwards a Layer 3 message to a 
5 particular device. The TCRM is then properly forwarded to 
the THD device- The details of talk group list management 
and control are well documented and will not be elaborated 
upon here . 

In some embodiments, the network performs 
appropriate filtering to reduce the number of TCRMs reaching 
the THD device. For example, in one embodiment, when 
multiple users send TCRMs, the network applies filtering to 
limit the number of TCRMs forwarded to the THD device or to 
limit the TCRMs forwarded to be only those TCRMs of specific 
users. In these embodiments, the network filters and 
forwards the TCRMs, preferably one at a time and in order. 
In other embodiments, when multiple users send TCRMs the 
network forwards all of the TCRM's to the THD device for 
storage in a queue, identifying the requesting user device 
or user in the order in which their respective TCRM was 
received. In these alternative embodiments, when more than 
one TCRM is received by the THD device, preferably the THD 
device user interface is arranged to display the user or 
device identification of each of .the users or devices for 
which a TCRM was received at the THD device. 

In some embodiments, receipt by the network of 
multiple messages from listening devices or the RHD device 
is dealt with. For example, in one embodiment when multiple 
TCRMs are sent by a single RHD device, only the first TCRM 
3 0 is forwarded to the THD device for a set flood protection 

duration during which time no further TCRMs are forwarded to 
the THD device. In some preferred embodiments, flood 
protection is performed by the RHD device of the listener. 
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by being unresponsive to additional listener initiated 
requests to generate a TCRM, until the flood protection 
period has expired. Such an embodiment reduces the cost of 
additional traffic on the network which could otherwise 
5 result from TCRM flooding. In another embodiment, flood 
protection is performed by the network, which forwards the 
first TCRM to the THD device and filters, for example by 
deletion, any subsequent TCRM from the same RHD device 
within the flood protection duration thereafter. It should 

10 be noted that, in this particular embodiment, within the 
flood protection duration of one RHD device, another RHD 
device may independently send a TCRM to the THD device. 
Once the flood protection duration has expired, the network 
then is free to forward another single TCRM received from 

15 the RHD device. These particular embodiments advantageously 
protect the network from unwanted flooding by the excessive 
transmission of TCRM messages. 

In an alternative embodiment, the TCRM is used to 
communicate a continual request status of the listener's 

20 wanting the talk/ transmit channel, which is active while the 
listener wishes to talk and inactive when the listener does 
not wish to talk. In such a preferred alternative 
embodiment the listener activates the request status by 
pressing and holding a button, after which the listener may 

25 release the button to deactivate the request status after 
deciding he or she no longer wishes to talk. In this 
particular embodiment the THD device displays the indication 
(visually, audibly, or otherwise) either periodically or 
continually until the status of the continuous request 

3 0 changes to inactive. 



Many different mechanisms involving the use of the 
TCRM may be used in accordance with this alternative 
embodiment, for example, in one embodiment the RHD device 



51085-3 

13 

transmits a TCRM periodically to the THD device to maintain 
an active request status, and does not transmit the TCRM 
when an inactive status is desired. In this case, the THD 
device uses a time-out period longer than the periodicity of 
TCRM transmission in order to determine that the listener is 
indeed no longer requesting the talk/transmit channel. In 
accordance with alternative input mechanisms, a user could 
activate or deactivate the request status in any number of 
different ways, including but not limited to soft-keys, UI 
menu interface, and the existing PTT™ button. Other 
alternative ways of deactivating the request status include 
the RHD device sending a separate ''cancel request message" 
to the THD device, or having the sending of any one TCRM 
toggle the request status, so that sending a second TCRM 
would suffice to deactivate the status. 

In an alternative embodiment, a queue is utilized 
at the THD device to store information for multiple TCRMs 
received by the THD device in the order in which they 
arrived at the THD device. In this alternative embodiment, 
2 0 when a user deactivates a request status the user is removed 
from the ordered list of requesting users. 

In some embodiments, during a single PTT"^'^ talk 
session, the network forwards a preset number of TCRMs, the 
preset number being less than a preset threshold, and does 

25 not forward any more TCRMs until a new talk session is 

begun. In some embodiments the preset threshold is related 
to the capacity of a THD device to store and/or to display 
information of a maximum number of TCRMs. In alternate 
embodiments the threshold is set according to settings 

30 resident in the Network which may originate from an 

administrator or a carrier. In one embodiment, the preset 
threshold is one. 
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In some embodiments, the THD device is adapted to 
receive and display in real time every TCRM it receives 
regardless of its storage or display capacity, utilizing 
first in first out (FIFO) TCRM buffers, for rotating storage 
5 and/or display. In some embodiments the THD device is 

capable of displaying only one TCRM related message at any 
one time. In other embodiments, the THD device is capable 
of storing only one TCRM at any one time. In other 
embodiments the THD device is adapted to store a group of 
10 TCRMs, and adapted to display messages related to a subset 
of the group of TCRMs . 

In some embodiments involving a queue, the THD 
device is adapted, such that once its FIFO buffers are 
filled to capacity, any additional TCRM received is simply 
15 ignored. In such an embodiment if an RHD device cancels a 
TCRM, the THD device is adapted to remove the relevant TCRM 
FIFO buffer entries so that the user display and data store 
may accept the next TCRM in the queue . 

In other embodiments, the THD device is adapted to 
2 0 perform automated tasks in response to receiving the TCRM, 
for example by executing a stored algorithm. In such an 
embodiment, the system could be set up, for example, such 
that in response to receiving a TCRM 3 6 with a UFMI of a 
certain value, the THD device would cause the talk/transmit 
25 channel to be released automatically. In general, the use 

to which the TCRM is put by the THD device may be other than 
solely for the display of information with respect to a 
request for the talk/transmit channel . 

In other embodiments, a receiving device which 
30 participates in calls of a PTT"^"^ group may be automated to 
make important voice announcements to the group. In this 
embodiment, if the listening automated device needs to make 
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an announcement during an active session, at step 110 it may 
send a TCRM message to the THD device whose user could 
respond to the request by releasing the talk/transmit 
channel so that the automated device may make the 
5 announcement to the group. 

In yet another embodiment, the sending and 
processing of the TCRM may be automated or partially 
automated at both the RHD device and the THD device. 

The TCRM and transmit channel request messaging 
10 method and system may be adapted for and used in any number 
of applications in a ptt"^^ or any other walkie-talkie-like or 
half-duplex voice communication system which would benefit 
from the capability of an RHD device to send to the THD 
device, a request for the transmit channel being held by the 
15 THD device. The reasons for sending the message and hence 
the functionality, if any, in response to the THD device's 
receipt of the TCRM will depend upon the use to which the 
transmit channel request messaging is put in the particular 
system in which it is implemented. 

2 0 Referring to FIG. 3, an example TCRM data 

structure in accordance with a further embodiment of the 
invention will now be discussed. It is to be clearly 
understood this is but one example. Any appropriate message 
format can be employed- For example, in a POC 

25 implementation, a DTMF tone may be used to request the talk 
channel . This DTMF tone is interpreted by the network as a 
TCRM, and a message identifying the wireless device is sent 
to the THD device. It is also to be understood that in a 
most simple embodiment, the TCRM is simply the same message 

30 that would be generated when a user presses the '"talk" 
button when the transmit channel is available. It is 
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interpreted as a TCRM by the network if the transmit channel 
is occupied. 

The example TCRM 36 is a datagram consisting of a 
header 40 and a payload 44. Depending upon the 
5 implementation of the system, the header 4 0 or the payload 
44 could be indicative that the message is a request for the 
talk/transmit channel, and that it should be forwarded to 
the transmitting device of the active session. The identity 
of the device making the request would preferably form part 

10 of the payload 44 as a device ID 50. In the iDEN™ system 
the payload preferably includes the UFMI of the receiving 
device. This can be used to identify the receiving device 
which has sent the request. In some embodiments, the 
payload includes a TCRM qualifier flag 53 which is used for 

15 extended functionality. In such an embodiment TCRM handling 
is further customized by the DAP or THD device performing 
different functionality. The TCRM qualifier flag 53 
contains information which may be indicative of, but not 
limited to the following: a state of the RHD device, the 

2 0 nature of the call, or the nature of the TCRM. In a 

specific preferred embodiment, the qualifier flag 53 may 
exhibit one of four machine readable values which indicate 
the following: Flag value 1 - RHD device making talk channel 
request; Flag value 2 - RHD device making a continuous talk 

2 5 channel request; Flag value 3 - RHD device 

terminating/canceling previous request; Flag value 4 - RHD 
device making high priority request for talk channel . 

In some embodiments. Flag value 1 is a default 
value for non- extended functionality of the TCRM. In such a 

3 0 case the THD device treats the TCRM the same way as it would 

treat a TCRM with no qualifier flag 53. In other 
embodiments Flag value 2 is a value to indicate that until 
the THD device receives a subsequent terminating or 
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canceling request from the RHD device, the current transmit 
channel request of the TCRM containing the qualifier flag 53 
stands. Flag value 3 is used to instruct the THD device 
that a previous request is cancelled, and therefore that the 
5 RHD device is no longer requesting the transmit channel. 

Flag value 4 enables the THD device to override the talker's 
choice to continue to occupy the transmit channel, the 
result of which is the automatic release by the THD device 
and hence the network, of the transmit channel. In a 

10 preferred embodiment not all devices have Flag value 4 as 
one of its TCRM qualifiers, in such a system classes of 
services are provided to differentiate between devices which 
can and cannot send TCRMs with Flag value 4 in the payload. 
In some embodiments, classes of services are registered on a 

15 DAP and managed thereby. In an embodiment capable of using 
Flag value 4, a mediator or administrator of a group, having 
a device capable of sending Flag value 4 in its TCRM would 
be able to interrupt the talker and possess the transmit 
channel . 

2 0 It should be understood that the particular 

structures and values of the qualifier flag 53 will depend 
upon the particular context in which the TCRM is used. The 
discussion above regarding four specific flags, and the four 
specific resulting kinds of functionality performed in 

2 5 response thereto, should be understood to constitute a 

discussion of an example only of the possible numbers, 
structures, and values of qualifier flags and possible types 
of functionality associated therewith. 

Referring again to the TCRM header 40, the header 

3 0 includes standard routing protocol and other headers 

required to transmit the message appropriately to the 
network, which ensures that that it is forwarded to the 
proper THD device of the active session in which the RHD 
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device is participating. In some embodiments adapted to the 
iDEN™ standard, the header 40 includes standard dispatch 
call control headers such as a protocol discriminator 
header, a transaction identifier header, and a transaction 
5 identifier flag header. In some embodiments another header 
"message type" is set to a value which is representative of 
the type of message being a TCRM. This may be the same 
value for incoming and outgoing TCRMs or may be set 
differently to distinguish between incoming and outgoing 
10 TCRMs. In some embodiments, the TCRM has a different 
structure when it is inbound from when it is outbound. 

In some embodiments the header of an incoming TCRM 
does not include a target UFMI of the THD device since the 
RHD device may not be aware of this. The network is capable 

15 of determining the THD device of the talk group in which the 
RHD device is participating. In some embodiments the header 
of an outgoing TCRM includes a target UFMI or other 
identification of the THD device in order for the network to 
forward it to the THD device. In some embodiments an 

20 outbound TCRM and an inbound TCRM have the same structure. 
In such embodiments, the inbound TCRM does not have an 
identification of the target THD device in the dispatch call 
control header. Space may be reserved in the TCRM for the 
dispatch call control header as it would be used in an 

2 5 outgoing TCRM. Depending upon the particular use to which 

the TCRM is put, and the particular system in which it is 
implemented, the structure of the TCRM datagram may change. 
The TCRM in a particular context preferably is such that it 
is sufficient when received by the THD device to notify the 

3 0 THD device that the talk/ transmit channel is requested. 



In some embodiments, the TCRM is simply broadcast. 
The THD device, being the only device in THD mode, will 
recognize the message as being for itself. In other 
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embodiments^ the TCRM is broadcast and contains an 
identifier of the THD device. In other embodiments the TCRM 
is sent on a device specific channel to the THD device in 
which case the identifier of the THD device might be 
5 required. 

Referring now to Figure 4, shown is a very- 
schematic diagram of a network adapted to provide the TCRM 
functionality- The network is generally indicated at 200. 
This functionality might for example include the 

10 functionality represented by links 25 and network 39 of 
Figure 1. The network provides wireless half duplex 
communications to accessing devices which may be wireless. 
The network 200 is shown having input channel 2 02 through 
which it is capable of receiving wirelessly the TCRM 208. 

15 This input channel can be any appropriate channel over which 
communications between a listening device and the network 
can take place. This might initially take place for example 
in a base station. Also shown within the network 200 is a 
message processing element 204. This element processes the 

20 incoming TCRM message 208, and determines where the message 
should be forwarded, namely to the device in the same talk 
group as the device that generated the TCRM 2 08 that is 
currently in the transmitting or talking mode. The message 
processing element 2 04 can be implemented in a single 

25 location within the network 200 or in a distributed manner. 
In a preferred embodiment, this is implemented within a call 
processing controller such as a DAP. The network 200 also 
has an output channel 206 through which is transmitted the 
TCRM 210 towards the device which is in talking mode. In a 

30 typical instance, the input channel 202, the message 

processing element 204 and the output channel 206 would be 
in different components within the network 200. However, 
this is not essential. One or more of these 
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elements/functionalities might be included within a single 
network element within the network 200. 

Although the example embodiments illustrated 
herein describe transmit channel request messaging and a 
5 TCRM which is specifically tailored to PTT"^"^ over the 
dispatch service of the iDEN^" system, in general the 
invention should be understood as not being limited thereto 
and therefor applicable to other systems which support but 
are not limited to, half -duplex voice communication, such as 
10 IxRTT CDMA, UMTS, GSM/GPRS, and TDMA. 

Referring to Figure 5, an example implementation 
of a PTT capable wireless device 3 00 provided by an 
embodiment of the invention, will now be discussed. 

Wireless device 300 is a wireless device modified 
15 by the implementation of functional elements provided in 
accordance with an embodiment of the invention. 

In the embodiment depicted in Figure 5, an input 
mechanism/ request receiver 310 includes a keypad 310a, and a 
touchscreen 340. Other embodiments could include any other 

2 0 suitable local input element and in some embodiments the 
wireless device 3 00 has a display screen instead of a 
touchscreen 340. The input mechanism/ request receiver 310 
is coupled to a TCRM processing/generator 320. The TCRM 
processing/generator 32 0 includes extended processing 

25 functions 320a which includes features such as filtering and 
flood protection. These functions are not necessarily 
present in other embodiments- The TCRM processing/generator 
32 0 is coupled to message transmission element 33 0a. The 
message transmission element 330a may share resources with a 

30 message reception element 330b. The message reception 

element 330b is coupled to the TCRM processing/generator 
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320. A storage element 340a and a display element in the 
form of a touchscreen 34 0 are each coupled to the TCRM 
processing/generator 320 • 

With respect to function, the wireless device 300 
5 depicted in Figure 5 is able to operate in THD mode and RHD 
mode . 

While in RHD mode, the wireless device is able to 
receive input from the input mechanism/request receiver 310 
by way of the keypad 310a and/or the touchscreen 340. These 
are provided to the listener to initiate the sending of a 
TCRM to a THD device while the wireless device 3 00 is in RHD 
mode. Once the request is input, the TCRM 
processing/generator 32 0 generates a TCRM including the 
identification of the wireless device 300 and forwards it 
through the message transmission element 33 0a over a logical 
control channel to a network (not shown) . 

While in TDH mode, the wireless device is able to 
receive a TCRM from the network over the message reception 
element 330b. The TCRM is input to the TCRM 
processing/generator 32 0, where it is processed for any 
required extra functionality, and a copy of which is saved 
in storage element 340a. Any necessary conversion of the 
information in the TCRM into human readable form is executed 
and the resulting indication displayed on the touchscreen 
340. 

In other embodiments, the TCRM 
processing/generator 320, storage 340a and input 
mechanism/ request receiver 310 cooperate to provide 
functionality associated with other embodiments described 
30 herein above. A specific example of a ptt"*^^ wireless device 
has been given. More generally, embodiments of the 
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invention are applicable to any wireless devices capable of 
participating in network provided walkie-talkie-like 
communication, which is further equipped with the capacity 
to send and receive and process TCRMs in a form suitable for 
5 a given implementation. 

In other embodiments, the method, system, and 
device are adapted to provide peripheral support for wired 
devices to participate in a wireless call via a network 
interworking function, so that although the devices are not 
within the wireless network, they appear as though they are, 
and are able to participate therein. Hence, according to 
this embodiment, not all of the devices in a PTT™ group are 
wireless, and transmit channel request messaging occurs in 
an analogous manner to that described hereinabove in PTT™ 
groups where one or more of the devices is a stationary or 
otherwise non-mobile wired device. Hence, a wireless PTT"^" 
session may have wired or landline based devices 
participating in the ptt™ session in accordance with the 
embodiments, adapted to transmit and receive messages for 
transmit channel request messaging. 

Numerous modifications and variations of the 
present invention are possible in light of the above 
teachings. It is therefore to be understood that within the 
scope of the appended claims, the invention may be practised 
25 otherwise than as specifically described herein. 
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